ORM(Object Relational Mapping)

Query Builder는 SQL을 더 안전하고 구조적으로 만들었지만,
여전히 데이터 접근의 기준은 SQL이었다.

개발자는 계속해서

어떤 테이블을 조회할지
어떤 조건을 사용할지
어떤 JOIN을 구성할지

를 SQL 관점에서 생각해야 했다.

관점의 변화

여기서 하나의 질문이 등장한다.

👉 “데이터를 굳이 SQL로 다뤄야 할까?”

애플리케이션은 객체 기반으로 동작하지만,
데이터베이스는 테이블 구조를 가진다.

이 둘의 차이를 줄이기 위해 등장한 것이
👉 ORM(Object Relational Mapping) 이다.

데이터 구조를 코드로 정의한다

ORM에서는 데이터베이스의 구조를
코드 레벨에서 정의한다.

예를 들어 Prisma 를 보면
다음과 같이 모델을 정의한다.

// Prisma schema
model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

이제 데이터베이스의 테이블 구조는
단순한 외부 리소스가 아니라
👉 애플리케이션 코드의 일부가 된다.

객체를 통해 데이터를 다룬다

데이터 조회 방식도 달라진다.

const user = await prisma.user.findUnique({
  where: { email: "test@test.com" }
});

여기서는 더 이상

SELECT 문을 작성하지 않고
WHERE 조건을 문자열로 만들지 않는다

👉 객체 구조를 통해 데이터를 조회한다

무엇이 달라졌는가

Query Builder와의 가장 큰 차이는
👉 “데이터를 표현하는 방식”이다

Query Builder → SQL 구조 기반
ORM → 객체 구조 기반

즉,

👉 SQL이 코드에 드러나지 않는다

자동완성과 타입 안정성

ORM에서는 스키마를 기반으로
코드 작성 시 다양한 이점이 생긴다.

const user = await prisma.user.findUnique({
  where: {
    email: "test@test.com"
  }
});

이 코드에서

email 필드는 자동완성으로 제공되고
잘못된 필드명을 사용하면 오류가 발생한다

👉 데이터 구조가 코드에 반영되기 때문이다

동적 조건 처리 방식의 변화

조건 처리도 객체 기반으로 표현된다.

const users = await prisma.user.findMany({
  where: {
    status: "ACTIVE",
    email: {
      contains: "@test.com"
    }
  }
});

문자열을 조합하는 것이 아니라
👉 객체를 구성하는 방식으로 조건을 표현한다

데이터베이스 추상화

ORM은 특정 데이터베이스에 대한 의존도를 줄여준다.

MySQL
PostgreSQL
SQLite

와 같은 다양한 데이터베이스를
👉 동일한 코드 구조로 사용할 수 있다

이로 인해 데이터베이스 변경 시
코드 수정 범위를 줄일 수 있다.

ORM의 장점

이 방식은 개발 생산성과 구조 측면에서 큰 이점을 가진다.

반복 코드 감소
비즈니스 로직과 데이터 접근 분리
코드 일관성 향상
객체 중심 설계 가능
타입 기반 개발 가능

특히 서비스 규모가 커질수록
이러한 장점이 더 크게 드러난다.

하지만 완전한 해결은 아니다

ORM은 많은 부분을 추상화하지만,
그만큼 새로운 문제도 발생한다.

실제 실행되는 SQL을 바로 확인하기 어렵다
성능을 세밀하게 제어하기 어렵다
복잡한 쿼리에서 표현 한계가 있다

대표적인 문제로는

N+1 문제
Lazy Loading / Eager Loading 이슈

등이 있다.

추상화의 대가

ORM은 SQL을 숨겨준다.

하지만 그만큼

👉 내부 동작을 이해하지 못하면
👉 예상하지 못한 성능 문제가 발생할 수 있다

즉,

편의성이 증가한 만큼
제어력은 일부 줄어든다

정리

지금까지의 흐름을 보면

Raw Query → 직접 제어
Query Builder → 구조적 개선
ORM → 객체 기반 추상화

로 발전해왔다.

👉 데이터 접근의 중심이
👉 SQL에서 객체로 이동한 것이다

다음 단계로의 흐름

하지만 하나의 방식이 모든 문제를 해결하지는 못한다.

상황에 따라

직접 SQL이 필요한 경우도 있고
구조적인 쿼리 생성이 필요한 경우도 있으며
객체 중심 접근이 유리한 경우도 있다

Keyboard shortcuts

데이터베이스 접근 계층의 이해